home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Tools & Utilities
/
Collection of Tools and Utilities.iso
/
dskut
/
handle20.zip
/
TSR.TXT
< prev
Wrap
Text File
|
1987-07-15
|
19KB
|
362 lines
July 1987
The History and Technology
of TSR Terminate and Stay Resident software
by
Steve Gibson
InfoWorld TechTalk Columnist and
President of Gibson Research Corp.
HISTORY BEGINS
----------------------------------------------------------------------
Once upon a time a Big Blue company named IBM decided that it wanted
to make personal computers too. For reasons known only to the Gods of
Boca Raton Florida, IBM decided to use the 8088 microcomputer from
Intel rather than Motorola's vastly "cleaner" 68000 (as is used in
Apple's macintosh). Viewed in retrospect, this has turned out to be a
ridiculously expensive, i.e. WRONG, decision. But anyway... IBM
journeyed to the West to get its software for this new machine.
IBM first visited the company who was then the acknowledged king of
operating systems, Digital Research, Inc. DRI had developed CP/M, the
defacto standard operating system for the very popular 8080 and Z80
microcomputer systems. IBM explained that it needed an operating
system for the new 8088 microprocessor in their new, blue, personal
computer and asked if DRI would please provide them with one. DRI
said, quite truthfully, that they didn't have one. Big blue must have
then asked if they would like to make one, to which DRI must have
again said: "No thanks."
IBM shrugged and headed North. . . . .
Though IBM may have only planned to ask Microsoft for an 8088 BASIC
language interpreter for their new machine, they found themselves in
Washington without an operating system. Microsoft said they would be
pleased to provide IBM with both an 8088 operating system and the
BASIC language interpreter. IBM said "Thank you" and said they needed
it very soon please.
But Microsoft didn't have an 8088 operating system either, and being
so very much smaller then than now, didn't have the resources to build
one from scratch by IBM's deadline. So they found an even tinier
company called Seattle Computer who had built a little unpretentious
operating system for the 8088 and 8086 micros called 86-DOS. It was
also known by some as QDOS. QDOS was said to stand for Quick and
Dirty Operating System.
So Microsoft, then able to meet IBM's 8088 machine timetable,
delivered both an operating system (albeit one of unassuming parentage
and questionable virtue) and a BASIC interpreter.
Everything seemed fine until we all began really using the new
operating system. We wanted additional and rather reasonable things
from MS-DOS and PC-DOS. Things which had not been designed into 86-
DOS, like printing in the background while the user was doing other
things. Or supporting RS-232 serial printers, which required routing
the printer data out through a serial port instead of the normal
parallel printer port.
To meet these reasonable demands Microsoft made a series of small
changes and additions to the guts of MS-DOS which allowed extra "add-
on" code to be "hung" onto the outside of MS-DOS and also provided for
limited communication between DOS and the add-on code. Microsoft's
idea was that these MS-DOS limitations would be "fixed" by writing
some new DOS commands (in the above examples PRINT and MODE) which
would make use of special undocumented aspects of their latest version
operating system.
The problem was that MS/PC-DOS, still really old 86-DOS (QDOS) in
disguise, was never built to support multitasking. This means that it
was never meant to serve more than a single master at a time. A
command like PRINT, which can continue to operate even AFTER the user
has begun doing something else, could very easily confuse it, since
now there could be service requests coming into MS-DOS from two quite
different places at once.
Since this began making the entire operating system rather fragile and
weird, Microsoft's grand plan was to retain all these special hooks
and communications paths as a company secret. They figured that as
long as they were the only ones to use these new MS-DOS secrets things
wouldn't get out of hand.
But Microsoft must have gravely underestimated the cleverness and
determination of the development community. When the MODE command
proudly stated: "Resident portion installed" developer's eyebrows shot
up! RESIDENT portion? Hmmmmmm. And if the PRINT command could
access the disk for file printing when we were messing around with a
spreadsheet, why couldn't we build a little resident notepad or two,
too?
But EVEN after these new resident goodies began appearing in
increasing numbers, Microsoft refused to "disclose" anything
whatsoever. They said they "couldn't" document these things or they'd
be forced to make all FUTURE versions of the operating system support
them in upwardly compatible fashion. Since these were awkward
"kludge" solutions to the real need for a true multitasking operating
system, Microsoft's delicate condition can be readily understood.
However, developers sensing massive market opportunities were not to
be stopped. Debugging software which allowed programmers to peer
inside the still working machine sold like wildfire. Using these
debuggers (like PERISCOPE, my personal favorite), developers probed
into the very heart of Microsoft's own PRINT and MODE commands,
unscrambling and deciphering the undocumented secrets of their
operation. Using the same secrets Microsoft's own developers had
used, they learned how to give their OWN programs similar
capabilities.
In an old episode of Star Trek, Mr. Spock said, after capturing the
Romulan's cloaking device, "...military secrets are the most fleeting
of all, Commander." This applies equally well to technological
secrets in general, and as we've seen, to Resident Software in
particular!
It's unfortunate that Microsoft did not have time back then in the
beginning to build their own DOS from scratch. They might have done
it right. But we're stuck with what we have today, and making the
most of it is certainly our best strategy.
It remains unfortunate, though certainly understandable, that
Microsoft isn't willing to disclose the details of MS-DOS's resident
software hooks and techniques. This policy keeps such knowledge quite
secret, since even the third-party developers are reluctant to
disclose their own hard-won "insider's" knowledge and proprietary
techniques for forcing reliable multitasking behavior from good ol'
single tasking DOS. It's quite interesting to speculate that perhaps
today even Microsoft does not KNOW how to write MS-DOS multitasking
applications as well and robustly as several of the larger commercial
resident software publishers! The tricks required to make DOS
multitask are real nasty stomach-turners.
So... what are these tricks and techniques? How DO resident programs
"pop up over" applications at the simple press of a "hot key"?
THE TECHNOLOGY OF RESIDENT SOFTWARE
----------------------------------------------------------------------
Since we've now know how we got to wherever it is we are, let's answer
the those questions posed above....
Two things are required for the functioning of TSR technology: First,
the TSR program needs to somehow "hang around" well after any other
program has started to run. Secondly, it has to "know" what's going
on in the system to be able to jump in and help out when called upon
for action. It also needs some way of re-assuming control of the
machine when the time comes for it to take action.
The requirement of continuing RAM residency is satisfied by a service
provided by the operating system from which TSR's get their name:
Terminate and Stay Resident (TSR).
The main operating RAM memory of an IBM compatible PC is a contiguous
block beginning at address zero (called the botto